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1. DESCRIPCIÓN DEL SISTEMA 


<Realizar una breve descripción del sistema a desarrollar> 


2. OBJETIVO 
<Especificar el objetivo a lograr con el desarrollo del sistema de información> 
3. JUSTIFICACIÓN 


<En este campo justifique para que se está realizando la actualización del aplicativo / Sistema, 
indicando módulos, submódulos y su funcionamiento. > 


4. ALCANCE DEL SISTEMA 
<En esta sección se incluirá una breve descripción del contexto del trabajo. Se proporciona una 
visión general de alto nivel acerca de las responsabilidades del sistema, se determinan los 


límites del sistema y los posibles subsistemas que lo componen. Se debe incluir código del 
sistema> 


5. HISTORIA DE USUARIO 


Las historias de usuario son utilizadas en los métodos ágiles para la especificación de 
requisitos, son una descripción breve de una funcionalidad software tal y como la percibe el 
usuario. 


<Ingresar la información del formato que se describe a continuación: 


HISTORIA DE USUARIO 
Identificación Historia de Usuario: 


Descripción: 


Prioridad: <Alto> 


Responsable: 


Observaciones: 


e Id: identificador de la historia de usuario, único para la funcionalidad o trabajo. 


e Título: título descriptivo de la historia de usuario. 
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e Descripción: descripción sintetizada de la historia de usuario. El estilo puede ser libre, 
según mejor funcione, debe responder a tres preguntas: ¿Quién se beneficia? ¿Qué se 
quiere? y ¿Cuál es el beneficio? 

Como [rol del usuario], se pretende [objetivo], para poder 
e Estimación: estimación del esfuerzo necesario en tiempo ideal de implementación de la 


historia de usuario. 


e Prioridad: sistema de priorización que nos permite determinar el orden en el que las 
historias de usuario deben de ser implementadas. (Alto, Medio, Bajo) 


e Riesgo: riesgo técnico o funcional asociado a la implementación de la historia de usuario. 
(Alto, Medio, Bajo) 


e Responsable: persona asignada para realizar la historia de usuario. 

e Sprint: incluir el número de sprint en el que previsiblemente se vaya a realizar la historia. 

e Valor: valor (normalmente numérico) que aporta la historia de usuario al cliente o usuario. 
El objetivo del equipo es maximizar el valor y la satisfacción percibida por el cliente en 
cada iteración. Este campo servirá junto con la estimación para determinar la prioridad con 


el que las historias de usuario deben de ser implementadas. 


e Validación: Estas son las pruebas que el código debe superar para dar como finalizada la 
implementación de la historia de usuario. 


e Observaciones: para enriquecer o aclarar la información o cualquier uso que pueda ser 
útil. 

6. PRODUCT BACKLOG 

Consiste en una lista con todos los requerimientos iniciales del producto que se va a 

desarrollar. Se trata de una lista dinámica, que irá evolucionando a medida que lo hace el 


producto y el entorno del proyecto. Se debe incluir requerimiento funcionales y no funcionales. 


<Ingresar la información del formato que se describe a continuación:> 


Identificador Titulo Estado Estimación  lteración Prioridad Comentarios 
(1D) de la (Sprint) 
Historia 


e identificador (ID) de la Historia: Código que identifica a la historia de forma unívoca, una 
vez asignado, no debe ser re-usado en otra historia, ni siquiera si la historia es descartada. 
El código identifica la historia en otros documentos, como por ejemplo la plantilla de 
historias de usuario. 
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e Título: título de la historia, el cual debe ser el mismo que se utiliza en otros documentos 
e Estado: Identifica los posibles estados de la historia durante su ciclo de vida: 


v Vacío: La historia fue identificada, pero aún no ha sido asignada a una iteración. 

Y Planificada: La historia fue asignada a una iteración y aún no ha comenzado su 
ejecución. Puede tener este estado incluyendo en la iteración donde está planificado 
ejecutarla (pero que aún no ha comenzado). 

Y” En Proceso: La historia fue seleccionada por el equipo y está en proceso de desarrollo 
(en ejecución). 

v Terminada: La historia fue desarrollada. Es importante clarificar la definición de 
“Hecho” con el equipo de trabajo. “Hecho” no sólo incluye el desarrollo sino la 
integración y pruebas integrales del Software. Una historia hecha puede presentarse al 
dueño de producto para sus pruebas de aceptación. 

Y” Descartada: Se determinó que la historia ya no es relevante, su contenido se incluyó 
en otro grupo de historias o fue cancelada. 


e Estimación: Medida del esfuerzo (tamaño) que implica desarrollar la historia, existen 
distintos métodos para medirlo, un ejemplo es los “puntos de historia” una medida de 
complejidad no necesariamente relacionado con jornadas o días. Otra forma de medirlo es 
con días o jornadas ideales. 

e iteración (Sprint): Iteración o Sprint al que se asigna la historia. 


e Prioridad: sistema de priorización que permite determinar el orden del requerimiento debe 
ser desarrollado. (Alto, Medio, Bajo) 


e Comentarios: Comentarios o detalles relacionadas que expliquen la historia. Para 


definiciones de mayor longitud deben usarse documentos externos, por ejemplo, la plantilla 
de historias de usuario. 


7. SPRINT BACKLOG 


La pila del sprint (sprint Backlog) es la lista de las tareas necesarias para construir las historias 
de usuario que se van a realizar en un sprint. 


<Ingresar la información del formato que se describe a continuación:> 


Identific Enuncia | Categ Tarea Respons Estat Horas Dia 1 Dia n Total 
ador (ID) do del oria able us estima 
de item item de das 
de Product totales 
product Backlog 
backlog 
Con Rest. Cons. Rest Cons. 
s. E 
<1> <Cambia <Desa | <Habili | <Luis <En <16 <6> | <10> <10> <0> <16> 
r rrollo tar el Muñoz> Proce horas> 
dirección | > campo so> 
de direcci 
cliente> ón> 
<Modifi | <Luis <En <16 <6> | <10> <10> <0> <16> 
car el Muñoz> Proce horas> 


Re 
st. 
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8. 


campo so> 
direcci 
ón> 


Identificador (ID) de item de product backlog: Código que hace referencia al elemento 
de la pila de producto (Product Backlog) al cual la tarea de la iteración hace referencia. 


Enunciado del item de Product Backlog: Enunciado o nombre del elemento de pila de 
producto (Product Backlog). En la mayoría de los casos, el nombre asignado al elemento 
de product backlog es el mismo de la historia de usuario 


Categoría: Tipo de tarea a realizar (Análisis- Diseño — Desarrollo - Documentación) 


Tarea: Nombre de la tarea de iteración (Sprint) especificada en esta línea, representa el 
elemento mínimo que se planifica. Para completar un elemento de product backlog se 
necesitarán ejecutar varias tareas, por ejemplo: Diseñar pantalla, vincular campos con la 
base de datos, definir procesos, configurar conexiones con interfaces o base de datos, 
entre otros. 


Responsable: Persona integrante del equipo Scrum que ha tomado responsabilidad de la 
tarea. 


Estatus: Estado actual de la tarea (Pendiente, En Proceso, Completo). 


Horas estimadas totales: Horas que han sido estimadas por el equipo Scrum que serán 
necesarias para ejecutar la tarea. La asignación de estimados se realiza durante la reunión 
de planificación de la iteración (Sprint Planning Meeting). 


Día 1 .... Día n: Una vez comienza a ejecutarse la iteración, se utilizan las columnas para 
llevar un registro de las horas que se han consumido en cada tarea y cuantas horas restan 
para completarla. 


Cons: Horas consumidas en la tarea en el día especificado. 

Rest.: Horas que restan luego de registrarse el consumo diario. Se calcula tomando las 
horas que restaban el día anterior y se resta las horas consumidas en el día. Si se trata del 
primer día, se restan las horas del día 1 al estimado de horas totales. 

Total: Registra la suma de todas las horas consumidas en el Sprint y las horas que restan 


finalmente. Las horas restantes deberían ser de cero si se logró ejecutar la tarea en su 
totalidad. 


PROTOTIPO DE PANTALLAS MOCKUP 


<En esta sección se incluirá la descripción de navegación a nivel de interfaz de usuario 
(Diagrama de navegación entre pantallas), se deberá mostrar el prototipo de pantallas del 
mismo (imágenes). Se podrá usar algún software de libre uso para la generación de prototipos 
previamente pactado con la Dirección TIC. Se incluirá la propuesta de diseño de interfaz de 
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usuario con los colores y logos definidos conjuntamente acorde con la imagen corporativa y las 
disposiciones de las diferentes dependencias.> 

9. Diseño de la Arquitectura 

<<En esta sección se establece la descomposición en subsistemas y las responsabilidades 
asignadas a cada uno. Corresponde a los productos obtenidos de las fases de análisis y diseño 
arquitectónico.>> 

9.1 Topología del Sistema 

< En esta sección se describirán la asignación del software al hardware — diagrama de 
despliegue> 

9.2 Politicas de seguridad 

< En esta sección se describen las políticas de seguridad y acceso que serán establecidas en 
el sistema — mecanismos de autentificación, encriptación, certificados, etc> 

9.3 Rendimiento y Tamaño 

< En esta sección se describen la capacidad de procesamiento y almacenamiento requerido 
para solución> 

10. Modelo de datos y diccionario de datos 

<<En esta sección del documento se agrega el diagrama entidad — relación con el diagrama de 
entidades de la base de datos. Adicionalmente se deberá complementar el diagrama entidad 
relación con la respectiva descripción detallada de cada una de las entidades y atributos como 
se muestra a continuación.>> 

10.1 Modelo Entidad — Relación 

<< En esta sección se deberá incluir el diagrama entidad relación desarrollado.>> 


10.2 Diccionario de datos 


Tabla 1 Diccionario de datos 


Número y nombre de | TBL - <#> < Escriba aquí el nombre de la entidad (Tabla) > 
la entidad 
Descripción < Escriba aquí la descripción de la nombre de la entidad (Tabla) > 
Nro. | Nombre de la Descripción Tipo de | Permitir | Llave Valor Auto 
Columna datos Valores Predeter | numér 
NULL minado ico 
<#> | < Escriba aquí | < Escriba aquí la |< < < < < 
el nombre de descripción de la | Escriba | Marque | Indiqu | Indique | Marqu 
la columna > columna > aquí el Slo NO |ePK- | aquí eSlo 
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tipo de permite | Para cual es NO es 
datos de | valores | llaves | elvalor | un 
la NULL > | primari | predeter | valor 
columna as o minado | auto 
> FK — si aplica | numér 
para > ico > 
llaves 
secun 
darias 
> 


9.4 Objetos adicionales de bases de datos 


<<En esta sección se incluirá la descripción de los demás objetos de bases de datos que sean 
necesarios para el desarrollo del proyecto.>> 


9.5 Procedimientos almacenados 


Tabla 2 Procedimientos almacenados 


Número y nombre del 
procedimiento almacenado 


SP - <> | < Escriba aquí el nombre del procedimiento 


almacenado > 


Descripción 


< Escriba aquí la descripción del procedimiento almacenado > 


Objetos de los que depende 


< Enumere los objetos de base de datos de los cuales depende 
el procedimiento almacenado > 


Objetos que dependen de 


< Enumere los objetos de base de datos que depende del 
procedimiento almacenado > 


9.6 Vistas de datos 


Tabla 3 Vistas de datos 


Número y nombre de la vista 


VS - <#>_ | < Escriba aquí el nombre de la vista > 


Descripción 


< Escriba aquí la descripción de la vista > 


Objetos de los que depende 


< Enumere los objetos de base de datos de los cuales depende 
la vista > 


Objetos que dependen de 


< Enumere los objetos de base de datos que depende la vista > 


9.7 Disparadores (Triggers) 


Tabla 4 Disparadores (Triggers) 


Número y nombre de la vista 


TR -<#>_ |< Escriba aquí el nombre del disparador (Trigger) > 


Descripción 


< Escriba aquí la descripción del disparador (Trigger) > 


Objetos de los que depende 


< Enumere los objetos de base de datos de los cuales depende 
del disparador (Trigger) > 


Objetos que dependen de 


< Enumere los objetos de base de datos que depende del 
disparador (Trigger) > 
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9.8 Tareas programadas (Jobs) 


Tabla 5 Disparadores (Triggers) 


Número y nombre del jobs VS - <#>_| < Escriba aquí el nombre del job > 

Descripción < Escriba aquí la descripción del job > 

Objetos de los que depende | < Enumere los objetos de base de datos de los cuales depende 
el job > 

Objetos que dependen de < Enumere los objetos de base de datos que depende el job > 


